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DOCKET NO: 026083-00005 



TITLE OF THE INVENTION 



EXPENSE TRACKING, ELECTRONIC ORDERING, INVOICE PRESENTMENT, AND 

PAYMENT SYSTEM AND METHOD 
[0001] This application claims priority from U.S. Provisional Application Serial No. 

60/431,438 titled "Method and System for Expense Tracking," filed December 6, 2002, 
and U.S. Provisional Application Serial No. 60/495,103 titled "Electronic Ordering, 
Invoice Presentment, and Payment System and Method," filed August 15, 2003. The 
entirety of each of those provisional patent applications is incorporated herein by 
reference. 



BACKGROUND OF THE INVENTION 

Field of the Invention 

[0002] The present invention relates to a method and system for electronic ordering, 

invoice presentment, and payment. 



Background of the Technology 
[0003] There exist in the art paper-based methods and systems for payment of invoices, 

but these systems are typically slow and costly for completing transactions. Automatic 
payment approval and presentment processes are also known, in which electronic 
invoices are provided and approved, but these processes do not include all functions 
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necessary for completion of a transaction (including, for example, payment). It is further 
known to provide electronic payment approval and dispute resolution processes, but 
without other necessary features for completion of a transaction. 
[0004] There remains an unmet need in the art to provide a wide range of electronic 

ordering, invoice presentment, and payment functions within a single method and 
system, which are useful, for example, for large organizations, such as mortgage 
service companies. 



SUMMARY OF THE INVENTION 
[0005] The present invention relates to the automated ordering, invoice presentment, 

and payment of third party goods and services. One embodiment of the present 
invention incorporates various aspects of applicant's copending U.S. Patent Application 
S.N. 09/512,845 titled "Method of Workflow Processing Through a Computer Network," 
filed February 25, 2000, and copending U.S. Patent Application S.N. 10/102,104 titled 
"Management and Reporting System and Process for Use with Multiple Disparate Data 
Bases," filed March 19, 2002, each of which is incorporated herein by reference. 
[0006] An embodiment of the present invention provides an automated and paperless 

method and system that combines presentment of invoices, use of an Automated 
Clearinghouse (ACH) system, electronic referencing of orders to presentment, 
electronic approval of payment, completion of payment via a network, such as the 
Internet or an intranet, and reconciliation, some or all of which occur online or via a 
processor or processors (one or more portions of the overall process also referred to 
interchangeably herein as "performing automated commerce"). In operation, for 
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example, the present invention allows participants (e.g., vendors, payors) to complete 
transactions wholly via the network using terminals and servers coupled to the network. 
Thus, for example, paper invoices are unnecessary, as electronic approval of delivery of 
goods or services is made, an ACH or other similar system assures transfer of payment 
to appropriate bank accounts, and transaction data is stored in a repository, such as a 
database. 

[0007] In one embodiment of the present invention, automatic payment and invoicing 

functionality interfaces with a company's existing software infrastructure. Users can 
therefore use the invention in conjunction with business software such as spreadsheet 
software or financial software to perform financial transactions. 

[0008] Features of the present invention include the following: 

1 ) Transaction system (e.g., REALTrans) vendor enrollment integration with 
other stand alone vendor systems (e.g., REALServicing and Infinium); 

2) Expense Tracking Work Order authorization process; 

3) Expense Tracking budgetary controls consistent with payor requirements; 

4) Payor electronic approval of controlled spending overages via a transaction 
system (e.g., REALTrans); 

5) Transaction system (e.g., REALTrans) automated electronic vendor invoice 
presentment and storage, with storage structured under, for example, asset number, 
and capability to automatically store invoices, copies of checks, and images (e.g., 
photographs); 

6) Capability to print invoices; 
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7) Vendor payment authorization and processing system (e.g., Infinium) 
consistent with system requirements; 

8) Calculation, assessment, and deduction of a transaction fee from payments; 

9) Electronic or other payment of vendor invoices through an ACH system by 
providing an interface between an Accounts Payable application (e.g., Infinium); and an 
ACH service provider; 

10) Automated billing of related invoices to the payor upon closing of a property 
by a direct interface between the Accounts Payable and Accounts Receivable 
applications; and 

11) Capability to identify unfunded budget items necessary to control trailing 
expenses. 

[0009] Additional advantages and novel features of the invention will be set forth in part 

in the description that follows, and in part will become more apparent to those skilled in 
the art upon examination of the following or upon learning by practice of the invention. 



BRIEF DESCRIPTION OF THE FIGURES 



[0010] 



FIGs. 1 A-1 D contain various aspects of a flow chart of functionality of interacting 



components for an example payor (VA), in accordance with an exemplary 



implementation of an embodiment of the present invention. 



[0011] 



FIG. 2 is an overview representative diagram of various system elements of an 



embodiment of the present invention. 



[0012] 



FIG. 3 presents an exemplary system diagram of various hardware components 



and other features in accordance with an embodiment of the present invention. 
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[0013] FIGS. 4A and 4B show an example flow diagram of a process for providing 

ordering, invoice presentment, and payment, in accordance with an embodiment of the 
present invention. 

[0014] FIG. 5 illustrates a computer system for carrying out expense tracking 

functionality, in accordance with an embodiment of the present invention. 
[0015] FIGS. 6-17 are example Graphical User Interface (GUI) screens that are 

presented to a user in accordance with an embodiment of the present invention. 
[0016] FIG. 18 is an example table showing payor budget limits, in accordance with an 

embodiment of the present invention. 
[0017] FIGS. 19-34 are example Graphical User Interface (GUI) screens that are 

presented to a user in accordance with an embodiment of the present invention. 

DETAILED DESCRIPTION 
[0018] Embodiments of the present invention relate to systems and methods for 

managing real estate transactions between a real estate owner or other property holder 
and one or more vendors. For example, the real estate owner is, in some cases, a 
corporation, bank, or other large entity with multiple real estate owned properties 
(properties). The real estate owner orders one or more services from the vendors in 
connection with the sale or management of a property or other transaction. The real 
estate owner is responsible for paying the vendors and is therefore interchangeably 
referred to herein as a "payor." 
[0019] In some embodiments, the invention relates to systems and methods for tracking 

expenses in conjunction with a transaction, such as the sale or management of a 
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property. The invention also relates to systems and methods for automated invoicing of 
goods and services. In one embodiment, the invention contains budget restrictions, 
such as a total budget maximum or a line item maximum for a particular item. Goods 
and services ordered or invoiced that exceed the budget restrictions must be approved 
by the payor and/or an employee of the company providing software services. The 
company managing the property on behalf of the real estate owner is interchangeably 
referred to as a Real Estate Owned company or an REO, and employees or managers 
at the REO are referred to as REO employees or REO managers. 

[0020] In one embodiment, the REO manages properties for a real estate owner. For 

example, a mortgage company may select the REO to manage the property because 
the mortgage holder is no longer making mortgage payments. In this case, the REO is 
responsible, for example, for collecting mortgage payments, for ordering repairs and 
other services, or for attending to the sale or foreclosure of the property. As another 
example, the property may have been foreclosed, and the property may belong to the 
REO itself, or to another owner. 

[0021] Embodiments of the present invention also relate to systems and methods for 

automated payment through, for example, an ACH system. After an invoice has been 
approved, the payor's account may be debited and the vendor's account may be 
credited. The invention also provides for fees, such as transaction fees, to be charged 
to the vendor and paid to the provider of software services. 

[0022] FIGS. 1 A-1 D contain various aspects of a flow chart of functionality of interacting 

portions of a transaction module (e.g., REALTrans), a service ordering module (e.g., 
REALServicing), and a payment module (e.g., Infinium) for an example payor, in 
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accordance with an exemplary implementation of an embodiment of the present 
invention. In this and subsequent examples, the exemplary payor or real estate owner 
is also referred to herein as "VA." 

[0023] As shown in FIG. 1 A, in one embodiment, a transaction module, system, or 

component provides functionality for vendor enrollment and for order delivery and 
invoice presentment. A service ordering module, system, or component provides 
functionality for creating budget and work orders within payor (VA) guidelines and for 
payor approval of overages. The service ordering module also receives invoice 
information from the transaction module and, using this information, provides 
functionality for invoice price validation and/or payor approval and write off of overage 
spending. The transaction module also provides functionality for invoice approval. 

[0024] In this embodiment, a payment module, system, or component receives invoice 

approval information from the service ordering module. The payment module provides 
functionality for electronic payment via an ACH, and also for a posting to the payor's 
accounts receivable (AR) account. The payment module also provides functionality for 
providing a payor invoice upon the completion of a transaction, such as the closing of a 
property, with an online invoice detail. 

[0025] FIGS. 1 B-1 C depict a flow chart illustrating the functionality of interacting 

components for an example payor (VA) and example vendor, in accordance with an 
exemplary implementation of an embodiment of the present invention. In step 1 , a 
vendor begins by enrolling in the transaction system. In step 2, the vendor and 
subvendor list is updated as new vendors sign up in the transaction system. In step 3, a 
pre-note is used to validate the bank information provided by the vendor. If the bank 
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information includes any invalid data, in step 4, the invalid data is sent back, for 
example, to the vendor and to the REO. The vendor may then choose to enroll in the 
transaction system with modified information in step 1 . 

[0026] In step 5, a budget is created or modified, for example, by an REO employee and 

within payor guidelines. The budget includes, for example, various work items to be 
performed and prices for each work item. The budget may be, for example, the budget 
for selling a property, and may include work items associated with selling the property, 
such as, for example, performing an inspection. Within the system, each work item 
may be associated with a work order, which is a request for a vendor to provide 
particular goods or services for a particular price. 

[0027] In one embodiment, the present invention uses a budget that is created, for 

example, by an REO employee in accordance with payor specifications. The budget 
includes such expenses as, for example, marketing expenses (such as agent fees, 
brochure or advertising fees), property maintenance fees (such as utilities, taxes, 
insurance, lawn care, or cleaning), repairs, inspections, rehabilitation, seller 
concessions, and closing costs. The budget may also include recurring items, which 
are items that require recurring payment (monthly, weekly, daily, etc.). A process is 
utilized to compare the original budget approved by the REO manager to the actual 
expenses being occurred. 

[0028] In one embodiment, the system provides features for recommending a marketing 

strategy for the property, either as-is or repaired. This may be accomplished by 
performing a calculation, taking into account factors such as an estimated as-is property 
value, an estimated repaired property value, and estimated repair costs. The system 
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also provides features that allow a user, such as an REO employee, to enter anticipated 
expenses for the property and compare budgets. In one embodiment, each budget may 
be associated with or include a business plan, which describes the rationale behind a 
particular marketing strategy for the property. A user can view or modify an existing 
business plan, or can create new business plans. In one embodiment, a business plan 
may include a "summary" field, which contains information such as a description of the 
property, any needed repairs, estimated costs, any recommendations made by the 
broker, proposed asking price, and any other information that may be useful in 
determining how to market the property. The business plan also includes a "plan of 
action" field, which contains information on how the property will be marketed, such as, 
for example, "List property as-is for $25,500 and if no offers in 30 days reduce." The 
business plan may also include an expiration date, and upon expiration of the business 
plan, the system will alert the user that the business plan must be modified or replaced. 
The user also has access to a budget spreadsheet, which lists all budgets and/or 
business plans that have been developed for the property. 
[0029] After a budget has been developed, in step 6, the budget is approved. This 

includes, in step 6.1 , determining whether the budget or expense type is above payor 
limits. This may be accomplished, for example, by making a query to a system table in 
a database, the system table including payor budgets by state and expense type. For 
example, a payor may specify that in the state of Virginia, the maximum expense for a 
flood order is $225, and the maximum budget is $5500; while in Texas, the maximum 
expense for a flood order is $150, and the maximum budget is $6000. This information 
is contained, for example, in a system table in a database, and a query to the database 



is used to determine whether the budget is above payor limits. The budget may be 
determined to be above payor limits if one line item exceeds the allowed line item 
maximum, or if the total budget exceeds the allowed budget maximum. If the budget is 
not above payor limits, the method continues in step 6.7.2. 

[0030] If it is determined that the budget is above payor limits, in step 6.2, it is 

determined whether an REO manager approves the overage. If the manager does not 
approve the overage, the budget is modified in step 5. 

[0031] If the manager approves the overage, in step 6.3, the overage is sent, for 

example, to the payor approval queue. This occurs, for example, if the budgeted 
amount for a particular order or line item is greater than a predetermined controlled 
amount, or if the total budgeted amount is greater than a predetermined allowable 
amount for the state in which the property is located. In step 6.7, it is determined 
whether the payor approves the overage. If the payor approves the overage, in step 
6.7.1 , a note is made of the approval, such as, for example, by adding a payor approval 
identification (ID) to each work order. 

[0032] In step 6.7.2, the controlled amount is added to the order for controlled 

expenses. In step 7, the REO assigns a vendor and subvendor to a work order for work 
specified in the budget. This may be performed automatically or manually. The vendor 
and subvendor are chosen, for example, from the vendor and subvendor list of the 
payment module. 

[0033] One embodiment of the present invention provides for a bidding process. In this 

embodiment, various vendors may create bids to perform work as specified in a work 
order or in a line item in a budget. Each of the bids includes, for example, a cost 
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estimate and other information. One of the bids may be selected, and the vendor will be 
assigned to the work order. In one implementation, selecting a bid occurs automatically i 
based on one or more criteria. For example, the bid with the lowest cost estimate may 
be selected. In another implementation, a user may select a bid. 

[0034] In step 8, the new work orders and payees are stored in the transaction system. 

In step 9, it is determined whether the vendor has changed the price that will be 
charged for the goods or services. If the vendor has changed the price, the method 
returns to step 5, wherein the REO creates a new budget. 

[0035] If the vendor has not changed the price, the vendor confirms the order in step 10, 

and in step 11, delivers the order, such as providing goods or services, and creates an 
invoice. This includes, for example, the vendor uploading the required invoice 
documents in step 11.1. The vendor may complete these documents to create an 
invoice. 

[0036] In step 12, the vendor transaction fees are calculated, and in step 13, information 

from the transaction module is extracted to the service ordering module. This 
information includes, for example, invoice details, transaction fees, and payor approval 
information. 

[0037] In step 14, it is determined whether the amount of the invoice for a work item is 

less than or equal to the amount specified in the work order or a preset overage 
tolerance for the work item. If the amount of the invoice is less than or equal to the 
amount specified in the work order or the preset overage tolerance, the method 
continues in step 17 of FIG. 1C. 



-11 - 



[0038] If the amount of the invoice is greater than the amount specified in the work 

order, in step 15, it is determined whether the REO manager approves the overage. If 
the REO manager does not approve the overage, the method continues with dispute 
management. This may result in the vendor creating a modified invoice in step 11. If 
the REO manager approves the overage, it is determined in step 15.1 whether the 
invoiced price is greater than the controlled amount specified in the system table. If the 
invoiced price is not greater than the controlled amount, in step 15.1.1, it is determined 
whether the revised budget is greater than the payor approved budget. If the revised 
budget is not greater than the payor approved budget, the method continues in step 17 
of FIG. 1C. 

[0039] If the invoiced price is greater than the controlled amount in step 15.1 or if the 

revised budget is greater than the payor approved budget, the method continues in step 
16 of FIG. 1C. 

[0040] Referring now to FIG. 1C, in step 16, the accepted price specified in the work 

order is amended to include the overage transaction, which is not reimbursable by the 
payor. In step 17, the REO reviews the work done for completion. 

[0041] In step 1 8, the invoice is sent to management for approval of the workflow. In 

step 19, it is determined whether the line items in the invoice have been approved. If 
one or more of the line items have not been approved, in step 21 .2, the unapproved line 
items are sent to the vendor for review and dispute management. This may result in the 
vendor creating a new invoice 11. 

[0042] If the line items have been approved, in step 20, the service ordering module 

sends the approved invoices and transaction fees to AP. In one embodiment, when an 
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invoice is received and approved, a user, such as an REO employee, creates a voucher 
by selecting from a list of outstanding work orders that match those on the invoice. The 
list may also include recurring items that are now due. The user can also create a 
voucher for an invoiced item for which no work order exists. The user enters verification 
information, such as the number of items and the total cost. Alternatively, the user may 
enter a new voucher into the system by inputting information into an electronic form. A 
batch of vouchers is automatically approved if every voucher in the system is approved. 
Alternatively, the user can manually approve a batch or an individual voucher. The 
approved batch is fed to the AP system for payment. 

[0043] In step 21 , the payment module periodically creates an accounts payable batch 

for the gross amount due to the vendor and for the transaction fees due to the REO. In 
step 22, the accounts payable batch is posted and payments via an ACH are 
scheduled. The payments are scheduled, for example, based on an approved 
remittance cycle to each vendor. 

[0044] In step 23, transactional information is extracted and sent to the service ordering 

module. In step 23.1, the transactional information is appended to the REO transaction 
history for the property. In step 23.1 .1 , unbilled receivables and other account 
information is stored in the payment module. The information stored in the payment 
module includes cash receipt (CR) information, which describes income on the property, 
and debit receipt (DR) information, which describes costs incurred in conjunction with 
the property. 
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[0045] In step 23.2, the batch posting of step 22 is used to generate information 

concerning accounts receivable for the provider of the software services. In step 23.3, 
information concerning the accounts receivable is stored in the Infinium module. 

[0046] In step 24, the payment module creates an ACH payment to the vendor. The 

payment amount is, for example, the amount due for services less the transaction fee 
due the REO. 

[0047] In one embodiment of the present invention, alternative methods of payment are 

provided. For example, some vendors may wish to be paid not via an ACH payment, 
but rather via an alternative method, such as a check. The system of the present 
invention provides for alternate payment methods, and provides functionality to record 
payments and transactions made by means other than an ACH. The present invention 
also, for example, provides functionality to assist in other methods of payment, such as 
functionality to generate and print a check. 

[0048] If the payment is successful, in step 25.1 , expense details in the service ordering 

module are updated with payment information, and in step 25.2, the order price stored 
in the transaction module for the particular goods or services may be updated. This 
price may be updated based on the work order expected price of step 16 as well as the 
payment data of step 25.1 . In step 25.3, information concerning the payment is written 
to the payment system. 

[0049] If the ACH payment is not successful, in step 26.1 , the payment transaction is 

added back to accounts payable. In step 26.2, the REO is notified to contact the vendor 
for updated bank details. In step 26.3, information concerning the failed payment is 
written to the Infinium module. 



-14- 



[0050] Referring now to FIG. 1 D, a method for closing on a property or otherwise 

completing a transaction begins in step 127, when a closing is scheduled. In step 128, 
an invoice of all pending work orders is sent to each vendor. This invoice includes a 
notice to the vendor that each pending or outstanding work order should be either 
completed and billed, or cancelled. In step 129, all pending work orders are closed. In 
one embodiment, this is performed at a predetermined time, such as three days before 
the closing of the property. In step 130, a notification is sent to each vendor with one or 
more pending work orders. The notification advises the vendor that the pending work 
order(s) has been canceled and that no further invoices will be accepted. 

[0051] In addition, in response to the closing scheduled in step 127, the budget is frozen 

in step 131 . In step 132, it is determined whether the REO can have a holdback 
amount. This is accomplished, for example, by querying a database. If the REO can 
have a holdback amount, for example, an Advance Accrual bucket and a Holdback 
Liability bucket in the service ordering module are populated with the total of confirmed 
and pending work order amounts. In step 133, the holdback advance and the holdback 
liability are stored in the payment module. 

[0052] In step 134, a payoff quote is created. This includes any existing holdback. In 

step 135, the property is closed, funds are deposited in the payor account, and the 
payor loan status is updated. As shown in step 136, the payor loan status may be set to 
one of the following: sold to independent third party, sold to payor homeless provider, 
sold to tenants, disposal, or withdrawn. Once the loan status has been set, changing 
loan status requires a manager approval. 
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[0053] In step 137, a fee due the provider of software services is calculated. Information 

used to calculate the fee includes, for example, the loan status drives, the sales price or 
mortgage payment of the property, and a rate applied to the sales price, the mortgage 
price, or the listing price. In the event prepayment has been made, the prepaid amount 
may be subtracted from the fee due. 

[0054] In step 138, a property closed report initiates an accounts payable extract 

posting. This is performed, for example, on a predetermined schedule, such as 30 days 
after the closing date. In step 139, the information from steps 137 and 138 is used to 
generate and post an accounts receivable extract batch. In step 140, information 
concerning accounts receivable, unbilled receivables, and income is written to the 
Infinium module. 

[0055] In step 141, an accounts receivable invoice is generated. In step 142, a vendor 

invoice detail is generated. In step 143, the accounts receivable invoice generated in 
step 141 and the vendor invoice detail generated in step 142 are sent to the payor for 
payment. 

[0056] In step 144, information from the accounts receivable invoice is written to the 

service ordering module as a comment concerning the loan. In step 145, information 
from the accounts receivable invoice, such as, for example, an invoice number or 
identifier, is written to the transaction module, along with the date. 

[0057] In step 146, cash received is entered into the accounts receivable account, and 

in step 147, information concerning the cash receipt (CR) is written to the payment 
module. 
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[0058] In one embodiment of the present invention, a user, such as an REO employee, 

has access to settlement processing features. Settlement processing features are 
used, for example, at the completion of a transaction, such as when a property has an 
accepted offer. A user performing settlement processing selects the property that has 
the accepted offer. The user is then presented with a settlement update window, which 
includes, for example, standard codes and descriptions of line items on a form, such as 
the HUD-1 form from the U.S. Department of Housing and Urban Development. 

[0059] To enter information for a line item on the form, the user may select the line item 

and enter the amount paid for that line item. For example, the user may select 
"City/town taxes paid by seller" and enter the amount paid. Some line items in the form, 
such as, for example, "Settlement charges to seller," will allow the user to detail sub- 
items for the line item. Selecting one of these line items brings up a sub-item window, 
wherein the user can list one or more sub-items and the cost for each. 

[0060] In one embodiment of the present invention, a user, such as an REO employee, 

has access to expense deduction features. Some expenses relating to work orders that 
have been paid, or have not yet been paid, can be reimbursed to the REO or to the 
vendor by deducting the amount from the sales proceeds. Expense deduction features 
are used, for example, to deduct these fees from the sales proceeds after a property 
has closed. 

[0061] The user selects the property and then selects the expenses to be deducted. 

The user then selects to pay the vendor through the AP system. The user can dictate 
how the vendor will be paid: either (1 ) directly at the time of closing from the sales 
proceeds, (2) reimbursed to the vendor at the time of closing, or (3) reimbursed to the 
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REO at the time of closing, and the REO then pays the vendor directly through the AP 
system. 

[0062] In one embodiment of the present invention, fees are defined as charges made 

by the REO to the payor for services performed. Example fees include delivery charges 
and postage charges. A user of the system, such as an REO employee, has access to 
fee deduction functionality. The fee deduction features are similar to the expense 
deduction features, except that the user selects fees rather than expenses to be 
deducted form the sales proceeds. 

[0063] In one embodiment of the present invention, the expense tracking, ordering, 

invoicing, and payment features interface with various external software applications. 
For example, a payor or vendor may use a spreadsheet program to create a budget, an 
ordering program to create an order for goods or services, or an invoicing program to 
create an invoice. The present invention may interact with these external software 
applications to track expenses, place orders, and make payments. Alternatively, a 
payor or vendor may use budgeting, ordering, or invoicing programs provided by the 
REO in conjunction with the present invention. 

[0064] FIG. 2 is an overview representative diagram of various system elements of an 

embodiment of the present invention. As shown in FIG. 2, the system includes a 
requestor 1 50 and a vendor 151 . The system also includes one or more databases or 
other data repositories. These data repositories include, for example, service ordering 
storage 152, transaction storage 153, accounts receivable storage 154, General Ledger 
(GL) storage 155, and accounts payable storage 156. The accounts receivable storage 
154, General Ledger (GL) storage 155, and accounts payable storage 156 may be 
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contained in the Infinium module. The data repositories include computer-readable 
instructions for carrying out functions associated with electronic billing, payment, and 
expense tracking. The data repositories further include information, such as vendor, 
property, budget, payor, and other information used in carrying out billing, payment, and 
expense tracking functionality. 

[0065] The system further includes one or more software modules, which are stored, for 

example, as computer-executable instructions, in the data repositories 152-156 or 
elsewhere. The software modules include functionality for performing various 
transactions for expense tracking. Software modules included in the system are, for 
example, an invoice creation module 157, a billing module 158, a billing presentment 
module 159, a charges module 160, a pricing module 161, and a vendor 
enrollment/setup module 162. Other software modules included in the system are, for 
example, an approval module 163, a dispute resolution module 164, an invoice module 
165, a constructive receipt module 166, and a payments module 167. 

[0066] FIG. 3 presents an exemplary system diagram of various hardware components 

and other features in accordance with an embodiment of the present invention. As 
shown in FIG. 3, in an embodiment of the present invention, data and other information 
and services for use in the system is, for example, input by a vendor 30 via a terminal 
31, such as a personal computer (PC), minicomputer, mainframe computer, 
microcomputer, telephone device, personal digital assistant (PDA), or other device 
having a processor and input capability. The terminal 31 is coupled to a server 33, such 
as a PC, minicomputer, mainframe computer, microcomputer, or other device having a 
processor and a repository for data or connection to a repository for maintained data, 
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via a network 34, such as the Internet, via couplings 35, 36. In one embodiment, a 
payor 39 also inputs information/data via a terminal 37 coupled 38 to the network 34. 

[0067] In operation, in an embodiment of the present invention, via the network 34, 

vendor and payor data and/or other information is communicated with the server 33. 
The server 33, which may optionally also include capability for communication with an 
electronic payment system, for example, receives, converts, formats and resolves the 
transaction, stores data regarding the transaction, documents the transaction (e.g., 
electronically), and assures payment completion. 

[0068] FIGs. 4A and 4B show an example flow diagram of a process for providing 

ordering, invoice presentment, and payment, in accordance with an embodiment of the 
present invention. As shown in FIG. 4A, a request for an ordered item, such as a good 
or service (e.g., order placement) first occurs 40, such as between a requestor (e.g., 
payor) and a transaction repository (e.g., transaction database). A receivable call (e.g., 
unbilled and in real time) is then generated from the transaction repository to a charging 
system 41. The receivable call includes, for example, information about accounts 
receivable, such as payment due from the payor for the ordered item. A journal entry or 
other record is transmitted to a general ledger (GL) repository (e.g., database) 42. 

[0069] As further shown in FIG. 4A, a pricing module is then accessed to determine the 

vendor/requestor price for the requested good or service 43. The order is placed with 
the vendor 44. A confirmation process then occurs 45, such as passing of a final 
agreed upon price and an original price through a charging module. A call (e.g., 
unbilled and in real-time) is then generated from the transaction repository to the vendor 
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46. The call includes, for example, information about accounts payable, such as 
payment due to the vendor for the ordered item. 

[0070] In an embodiment of the present invention, upon approval, a communication 

occurs from the vendor to the transaction repository and to the requestor 47. The 
transaction repository then communicates approval to the charging system 48, and an 
electronic invoice is generated 49. The invoice is approved 50, billing presentment 
occurs 51 , any dispute resolution occurs 52, and payment is made 53. Information 
regarding the transaction is then communicated to an accounts payable (AP) repository, 
the GL repository, and an accounts receivable (AR) repository 54. 

[0071] The present invention may be implemented using hardware, software or a 

combination thereof and may be implemented in one or more computer systems or 
other processing systems. In one embodiment, the invention is directed toward one or 
more computer systems capable of carrying out the functionality described herein. An 
example of such a computer system 200 is shown in FIG. 5. 

[0072] Computer system 200 includes one or more processors, such as processor 204. 

The processor 204 is connected to a communication infrastructure 206 (e.g., a 
communications bus, cross-over bar, or network). Various software embodiments are 
described in terms of this exemplary computer system. After reading this description, it 
will become apparent to a person skilled in the relevant art(s) how to implement the 
invention using other computer systems and/or architectures. 

[0073] Computer system 200 can include a display interface 202 that forwards graphics, 

text, and other data from the communication infrastructure 206 (or from a frame buffer 
not shown) for display on the display unit 230. Computer system 200 also includes a 
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main memory 208, preferably random access memory (RAM), and may also include a 
secondary memory 210. The secondary memory 210 may include, for example, a hard 
disk drive 212 and/or a removable storage drive 214, representing a floppy disk drive, a 
magnetic tape drive, an optical disk drive, etc. The removable storage drive 214 reads 
from and/or writes to a removable storage unit 218 in a well known manner. Removable 
storage unit 218, represents a floppy disk, magnetic tape, optical disk, etc., which is 
read by and written to removable storage drive 214. As will be appreciated, the 
removable storage unit 218 includes a computer usable storage medium having stored 
therein computer software and/or data. 

[0074] In alternative embodiments, secondary memory 210 may include other similar 

devices for allowing computer programs or other instructions to be loaded into computer 
system 200. Such devices may include, for example, a removable storage unit 222 and 
an interface 220. Examples of such may include a program cartridge and cartridge 
interface (such as that found in video game devices), a removable memory chip (such 
as an erasable programmable read only memory (EPROM), or programmable read only 
memory (PROM)) and associated socket, and other removable storage units 222 and 
interfaces 220, which allow software and data to be transferred from the removable 
storage unit 222 to computer system 200. 

[0075] Computer system 200 may also include a communications interface 224. 

Communications interface 224 allows software and data to be transferred between 
computer system 200 and external devices. Examples of communications interface 224 
may include a modem, a network interface (such as an Ethernet card), a 
communications port, a Personal Computer Memory Card International Association 
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(PCMCIA) slot and card, etc. Software and data transferred via communications 
interface 224 are in the form of signals 228, which may be electronic, electromagnetic, 
optical or other signals capable of being received by communications interface 224. 
These signals 228 are provided to communications interface 224 via a communications 
path (e.g., channel) 226. This path 226 carries signals 228 and may be implemented 
using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) 
link and/or other communications channels. In this document, the terms "computer 
program medium" and "computer usable medium" are used to refer generally to media 
such as a removable storage drive 214, a hard disk installed in hard disk drive 212, and 
signals 228. These computer program products provide software to the computer 
system 200. The invention is directed to such computer program products. 

[0076] Computer programs (also referred to as computer control logic) are stored in 

main memory 208 and/or secondary memory 210. Computer programs may also be 
received via communications interface 224. Such computer programs, when executed, 
enable the computer system 200 to perform the features of the present invention, as 
discussed herein. In particular, the computer programs, when executed, enable the 
processor 204 to perform the features of the present invention. Accordingly, such 
computer programs represent controllers of the computer system 200. 

[0077] In an embodiment where the invention is implemented using software, the 

software may be stored in a computer program product and loaded into computer 
system 200 using removable storage drive 214, hard drive 212, or communications 
interface 224. The control logic (software), when executed by the processor 204, 
causes the processor 204 to perform the functions of the invention as described herein. 
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In another embodiment, the invention is implemented primarily in hardware using, for 
example, hardware components, such as application specific integrated circuits 
(ASICs). Implementation of the hardware state machine so as to perform the functions 
described herein will be apparent to persons skilled in the relevant art(s). 

[0078] In yet another embodiment, the invention is implemented using a combination of 

both hardware and software. 

[0079] FIGS. 6-34 are example GUI screens that are presented to various users in 

accordance with an embodiment of the present invention. In this particular 
embodiment, the transaction module is referred to as a REALTrans module, the service 
ordering module is referred to as a REALServicing module, and the payment module is 
referred to as an Infinium module. FIGS. 6-17 are example GUI screens that are 
presented to a user wishing to enroll a vendor in the transaction module, or REALTrans 
system, to provide goods or services. 

[0080] A user, such as a vendor, wishing to enroll in a system of the present invention, 

such as a REALTrans system, is first presented with the GUI screen illustrated in FIG. 
6, and is presented with user agreements including a new transaction agreement. If the 
user agrees to the terms, for example, by selecting a button on the screen, the user is 
presented with the GUI screen of FIG. 7. This GUI screen alerts a user that the 
enrollment process will require certain information, such as, for example, bank account 
information. The GUI screen of FIG. 8 requests registration information from the user, 
such as, for example, whether the user wishes to add a new company or add a new 
branch to a corporate hierarchy. 
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[0081] The GUI screen of FIG. 9 prompts the user to enter information in various fields. 

The information includes, for example, company name, business name, type of 
business (such as, for example, individual, sole proprietor, corporation, partnership, or 
other), whether the business is exempt from backup withholding, tax identification 
number or social security number, business address, tax certification information, and 
personal information (such as, for example, address, phone number, fax number, cell 
phone number, and email address). 

[0082] The GUI screen of FIG. 10 prompts the user to enter the role the business will 

play in the system. The roles played by one business or individual may be represented 
differently in different modules of the system. For example, in one embodiment, the role 
of a business or individual is described in the REALTrans module as one of the entries 
shown in FIG. 10. In embodiments, the role of a business or individual dictates 
whether their information will be stored in the REALTrans module, a service ordering 
module such as a REALServicing module, a payment module such as an Infinium 
module, or some combination thereof. Storing information in the Infinium module in 
some cases includes creating an Accounts Payable (AP) account for the business or 
individual. The type of business or individual is described in the REALTrans module as 
one of appraiser, attorney, automated valuation service provider, builder, correspondent 
lender, credit bureau, flood determination provider, government sponsored entity, 
investor, lender, management firm, mortgage exchange, mortgage insurance provider, 
pest inspection provider, real estate agent, servicer, special servicer, sub-servicer, 
survey provider, title company, verification service provider, or wholesale lender. The 
type of business or individual is described in the REALServicing module as one of 
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appraiser, association/condo, attorney, auto insurance, bank, bankruptcy court, 
bankruptcy trustee, client, insurance agency, insurance company, investor, land-no 
insurance, miscellaneous, not applicable, optional insurance, real estate agent, reserve 
replacement, servicer, sub-servicer, tax service, third party, US trustee, interim Housing 
and Urban Development representative, lockbox. The type of business or individual is 
described in the Infinium module or AP system module as one of appraisal services, 
employee, facilities and service provider, government and regulatory, non employee 
individuals, law firms and related, professional services, property management and 
related, realtors, technology and related, title companies. 

[0083] Allowing corporations, entities, and individuals to enroll as "vendors" in the 

system provides, for example, for automatic payment to these corporations, entities, 
and individuals. For example, allowing an attorney to enroll as a vendor allows for 
expense tracking and automatic payment of attorney's fees in conjunction with a 
foreclosure or other legal service. Similarly, allowing a city, county, or state to enroll as 
a vendor provides for automatic payment of taxes and other government fees., and 
allowing a utility company to enroll as a vendor provides for automatic payment of utility 
bills. Other expense tracking, ordering, invoicing, and payment functionalities for other 
vendor types are possible. 

[0084] In one embodiment of the present invention, a user may act as an agent for a 

vendor within the system. For example, a user such as a real estate broker may enroll 
a vendor, such as a landscaper, in the system. This allows, for example, the 
landscaper to receive automatic payment without expending the time and effort to enroll 
in the system. 
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[0085] The GUI screen of FIG. 1 1 prompts the user to enter credit card details, 

including, for example, cardholder name, type of card, card number, expiration date, 
and billing address. The GUI screen of FIG. 12 prompts the user to enter bank details, 
including, for example, bank name, bank address, bank account number, and bank 
routing number. The GUI screen of FIG. 13 alerts the user to the fact that the account 
has successfully been created, and allows the user to select "Service Areas." The user 
selects "Service Areas" if the user is a vendor. This allows the user to specify the areas 
the vendor serves. 

[0086] After selecting "Service Areas," the user is displayed the GUI screen of FIG. 14, 

and is prompted to enter a service area name and service area description. The GUI 
screen of FIG. 15 prompts the user to enter the states in which the vendor does 
business. The GUI screen of FIG. 16 prompts the user to enter the counties in each 
selected state in which the vendor does business. The GUI screen of FIG. 17 prompts 
the user to enter the zip codes in each selected county in which the vendor does 
business. 

[0087] Once the vendor has been enrolled, an interface between the REALTrans and 

REALServicing modules captures the new vendor for upoload to the REALServicing 
module, and then to the Infinium module. In one embodiment, a batch process uses 
File Transfer Protocol (FTP) to periodically send information about new vendors to both 
the REALServicing and Infinium modules. The information is also sent to an accounts 
payable database. The information includes, for example, vendor name, vendor 
identification number, vendor type, vendor contact information (type, phone type and 
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number, email) vendor address, vendor class, and vendor bank details (bank routing 
number, account number, account name). 

[0088] The bank data is then validated, for example, by running a pre-note. The pre- 

note may be a regular ACH transaction with a zero dollar amount. Failed payments 
or pre-notes are sent to a queue to be reviewed by a staff member. The staff member 
then contacts the vendor to validate and correct the bank information, and the payment 
or pre-note is resubmitted using the corrected information. 

[0089] When a REO is ready to market a property, the REO creates a budget for the 

property. The budget must comply with predetermined limits set by the payor contract. 
Example total budget limits for one payor, listed by state, are shown in the table of FIG. 
18. In addition, each line item or transaction in the budget must comply with limits set 
by the payor for each expense type. The GUI screen of FIG. 19 illustrates sample 
expense types for each line item or transaction in the budget. 

[0090] FIGS. 20-34 are example example GUI screens that are presented to a user 

wishing to perform and manage various transactions associated with the sale or 
management of a property. The GUI screen of FIG. 20 illustrates a budget 
spreadsheet created for a property. The user adds items to the budget spreadsheet 
and submits the budget, for example, by clicking a "submit" button. 

[0091] After the budget has been submitted, the system identifies whether any line items 

in the budget exceed the limits the payor has set, or whether the total budget exceeds 
the payor limit. If line items in the budget exceed the limits or the total budget exceeds 
the payor limit, an REO manager has a choice to approve or deny the overage. The 
GUI screen displayed to the manager is shown in FIG. 21. The manager has the option 
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to approve each line item. For example, by checking a check box. If the overage is 
denied, the budget is sent back to the REO for modification. 
[0092] After the budget has been approved by the manager, a workflow is sent to the 

payor, describing the line item transactions that will occur. An email notification is sent 
to the payor. The email notification is illustrated in FIG. 22. The notification includes 
information concerning the overbudget line item and may prompt the payor to approve 
the line item. The payor may approve the line item, or may select "Review Order in 
REALServicing." 

[0093] Selecting "Review Order in REALServicing" will display the approval report 

screen displayed in FIG. 23. The approval report screen shows all line items open for 
payor approval, and allows the payor to approve the line items From the approval 
report screen, the user can access the budget summary illustrated in FIG. 24. The user 
clicks on a specific line item to view information for the line item, as illustrated by the 
GUI screen of FIG. 25. From the GUI screen of FIG. 25, the user can choose to 
approve the overage. 

[0094] After the REO manager and the payor have approved any overages, a work 

order for each line item is created, for example, by the REALServicing module. The 
GUI screen of FIG. 26 is displayed to the REO. From the GUI screen of FIG. 26, a user 
may select a vendor and/or subvendor for each work order by selecting from the list of 
vendors and subvendors in the REALTrans module. This may be accomplished, for 
example, by selecting from a drop-down box. The work order is then stored in the 
REALTrans and REALServicing modules. 
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[0095] After a work order has been created and a vendor selected, the vendor may 

change the price on the work order. If this occurs, the change is reflected in the budget 
and stored in the REALServicing module, and the budget must be approved again. 
The budget may be approved automatically, or by manager and payor approval, 
depending on whether the revised budget contains an overage. 

[0096] After the vendor has been selected and the budget re-approved if necessary, the 

vendor is presented with the GUI screen of FIG. 27, and may choose to confirm, 
decline, or conditionally confirm the order. If the vendor chooses to conditionally 
confirm the order, the vendor may input conditions, such as, for example, a modified 
due date, a modified order price, and modified order costs, and the order is sent to the 
REO and the payor for approval of the conditions. 

[0097] If the vendor chooses to decline the order, the REO chooses another vendor for 

the order. The REO may then select "Order Inquiry" to view the GUI screen of FIG. 28. 
The REO can view outstanding orders that have been deleted or conditionally 
confirmed, and can select an order and update the vendor. 

[0098] The vendor delivers the order or otherwise provides goods or services described 

in the work order, and creates an invoice. The vendor may create the invoice using the 
electronic invoice form of FIG. 29. The invoice contains a delivered price, which is the 
price the vendor charges for the goods or services. This amount may be the confirmed 
order amount in the budget, or another amount that is either higher or lower than the 
confirmed order amount. 
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[0099] The REALTrans module calculates the transaction fee due to the provider of 

software services. This may be or include a flat transaction fee, or a percentage of 
invoiced amount or the confirmed order amount. 

[0100] The invoice is then sent to an approval queue in the REALServicing module. 

From an Expense Tracking menu in the REALServicing module, a user may select 
"Invoice Approval Queue," as shown in FIG. 30, to view pending or approved invoices. 
The invoice may be approved automatically or by the user. Approval includes, for 
example, comparing the invoiced amount to the confirmed order amount or checking 
whether the payor has approved an overage. 

[0101] Certain invoices are queued to the REO manager for approval. These invoices 

include, for example, invoices that exceed the payor-approved allowable amount, the 
pre-approved budget. In one embodiment, the REO manager is provided with the GUI 
screen of FIG. 31, which allows the manager to select certain transactions. The 
manager may search all transactions, rejected transactions, or transactions over the 
payor approved amount (VA overages), and may enter other search criteria as well. 

[0102] The REO manager will then be presented with a report, such as that shown in 

the GUI screen of FIG. 32. From the report, the REO manager can select a particular 
invoice, and is then presented with details for the invoice, as shown in the GUI screen of 
FIG. 33. 

[0103] From the GUI screen of FIG. 33, the REO manager can approve the overage, 

and the budget in the REALServicing module is amended to include the overage. The 
manager can also select "Not approved," in which case the work order is sent to the 
REALTrans module for dispute management. 
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[0104] If the revised budget exceeds the payor total budget limit, a note is made that the 

overage is not eligible to be reimbursed by the payor. If the invoiced amount is less 
than or equal to the budgeted amount, or if the invoiced price is equal to the payor 
approved price, the work order is sent to the REO to be validated. The REO is 
presented with the GUI screen of FIG. 34 to verify that the work was completed. 

[0105] The invoice is then approved. In one embodiment, if the invoice is not approved 

within a predetermined time, an email notification may be sent to an alternate manager. 
Once the invoice has been approved, the REALServicing module sends the approved 
invoice and the calculated transaction fee to an accounts payable database. If the 
invoice is rejected, a transaction is sent to the REALTrans module changing the order 
status to "rejected." 

[0106] In one embodiment, a periodic process creates an accounts payable (AP) batch 

for each invoice due each vendor less the transaction fee for the invoice. The total 
amount of each vendor invoice is uploaded into the Infinium module. The transaction 
fee associated with the vendor invoice is uploaded as a debit memo (negative invoice). 
The AP batch is posted, and ACH payments are scheduled based on approved 
remittance cycles to vendors. 

[0107] An AP file feeds the REALServicing module. In one example, an approved 

invoice includes a transaction, the cost of which can be recovered by the payor, and a 
supplemental FB transaction. The accepted invoice is higher than the budgeted 
amount. Information about the invoice is written to the GL, and accounts payable 
details are transferred to accounts receivable. These unbilled invoices remain in 
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accounts receivable until the property closes. A periodic interface extracts information 
from REALServicing to the GL. 

[0108] The AP system generates an ACH payment to the vendor, net of the transaction 

fees. The vendor ACH payment is scheduled based on the payment date entered 
during invoice approval or based on the vendor file in the Infinium module. The Infinium 
module creates an ACH payment file on a periodic basis. The contents of the file are 
verified and payment is submitted to the vendor bank. If the payment is successful, the 
ACH details are sent to the REALServicing module, which updates the corresponding 
work orders and budget, and to the REALTrans module, which updates the order. The 
accounts payable and cash data in the Infinium module are updated accordingly. 

[0109] If the ACH payment is not successful, the transaction amount is added back to 

accounts payable, and the REO is notified to contact the vendor for update bank details. 
The accounts payable and cash data in the Infinium module are updated accordingly. 

[0110] After ACH payment has been made, the REO closing is scheduled. A pending 

close notice is sent to vendors with outstanding orders. The pending close notice 
contains a report of the work orders and pending vendor invoices, and alerts the vendor 
that remaining invoices must be submitted within a predetermined amount of time, such 
as, for example, three days. The work orders are then updated to reflect an estimate of 
the remaining amount to be billed by the vendors. A payoff quote is created. 

[0111] The property is closed and the status of the property in the system is updated. 

The sale also initiates the calculation of a transaction fee that is based, for example, on 
the sales price of the property. A bill is created and sent to the vendor, and the system 
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proceeds, (2) reimbursed to the vendor at the time of closing, or (3) reimbursed to the 
REO at the time of closing, and the REO then pays the vendor directly through the AP 
system. 

[01 16] In one embodiment of the present invention, fees are defined as charges made 

by the REO to the payor for services performed. Example fees include Federal Express 
charges and postage charges. A user of the system, such as an REO employee, has 
access to fee deduction functionality. The fee deduction features are similar to the 
expense deduction features, except that the user selects fees rather than expenses to 
be deducted form the sales proceeds. 

[0117] In one embodiment of the present invention, a user, such as an REO employee, 

also has access to reporting pages, such as, for example, a statement of expenses, 
which includes an automatically generated report of all expenses invoiced on a 
property; and a financial snapshot, which provides a detailed list of all paid expenses 
associated with a property. 

[0118] Example embodiments of the present invention have now been described in 

accordance with the above advantages. It will be appreciated that these examples are 
merely illustrative of the invention. Many variations and modifications will be apparent 
to those skilled in the art. For example, while the invention has primarily been 
described in terms of systems and methods for tracking expenses throughout a real 
estate transaction, the invention is applicable to other transactions, such as, for 
example, medical insurance reimbursements, construction projects, and retail or other 
transactions. For example, the invention can be practiced in conjunction with 
construction on a property. The budgeting ordering, and invoicing functionality can be 
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used to create a budget for construction materials and labor costs, and to order and 
invoice these materials and costs. Other modifications will be apparent to those skilled 
in the art. 
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